For ref #1168

Hi @cparata,
I had in mind (according to #1168 discussion) that we go toward a symmetric approach, meaning that
in stm32_interrupt_disable() we should disable EXTI too (in addition to NVIC).
And instead of calling HAL_GPIO_DeInit()/HAL_GPIO_Init() to keep GPIO mode,
I suggested to use LL EXTI API (even if EXTI API was not directly used in stm32_interrupt_enable(), it is used indirectly in HAL_GPIO_Init(), thus no symmetric break).

Hi @ABOSTM ,
in fact, this is what I would like to test. I will update the PR asap I have the opportunity to implement the stm32_interrupt_disable() with the LL HAL.
Best Regards,
Carlo

My only concern about the usage of LL HAL is portability. It is not said that LL HAL is available for all STM32 families; this is the reason why I suggested the usage of the HAL_DeInit that instead should be available for all STM32 families.

Hi all,
I remanaged the PR, modifying only the "stm32_interrupt_disable". I implemented it using the gpio DeInit because I guess it is the simplest way to do it and it is also the most portable. Let me know if you have any comment. Unfortunately, I cannot test it with motor driver until Wednesday, when I will be in the office.
Best Regards,
Carlo

I was able to test the new PR with the motor driver and it works as expected on my side. So, for me this implementation is functional.

Hi @ABOSTM ,
I'm not really expert on LL APIs. Unfortunately, at the moment I do not have band to investigate better on this topic. Anyway, from the testing that I did, it is sure that if we are able to reset in some way the EXTI settings during the stm32_interrupt_disable(), the issue that I see on motor driver will be solved. So, if you are able to find a more efficient way to do that, it is fine for me as well.
Best Regards,
Carlo

Hi guys,

I was meeting troubles with a STM32L072 just trying to use interrupt with a button generating some rebonds and I found this PR. I applied modifications but it's not enough for me. I had to add __HAL_GPIO_EXTI_CLEAR_IT() in order to get the expected behaviour.

My (working) code :

const int butPpin = PA1;
volatile byte flag = 0;
volatile byte flag2 = 0;
volatile int count = 0;


void setup() {

  Serial.begin(115200);
  while (!Serial);
  delay(500);
  pinMode(butPpin, INPUT_PULLUP);

  attachInterrupt(digitalPinToInterrupt(butPpin), intInt, FALLING);

}

void loop() {

  if (flag) {

    flag = 0;
    Serial.println("ping ! ");
    Serial.println(count);
    delay(1000);

    attachInterrupt(digitalPinToInterrupt(butPpin), intInt, FALLING);

  }

}


void intInt()
{

  detachInterrupt(digitalPinToInterrupt(butPpin));

  __HAL_GPIO_EXTI_CLEAR_IT(butPpin);
  flag = 1;
  count++;
}

If __HAL_GPIO_EXTI_CLEAR_IT(butPpin); is commented, I get an extra interrupt

Hi @battosai30 ,
actually for debouncing it is not needed to use this API. You can try something like this:

const int butPpin = PA1;
volatile byte flag = 0;
int count = 0;
int PushButtonState = 0;


void setup() {

  Serial.begin(115200);
  while (!Serial);
  delay(500);
  pinMode(butPpin, INPUT);

  /* Check what is the Push Button State when the button is not pressed. It can change across families */
  PushButtonState = (digitalRead(butPpin)) ?  0 : 1;

  attachInterrupt(digitalPinToInterrupt(butPpin), intInt, FALLING);

}

void loop() {

  if (flag) {
    /* Debouncing */
    delay(50);

    /* Wait until the button is released */
    while ((digitalRead( butPpin) == PushButtonState));

    /* Debouncing */
    delay(50);

    count++;
    /* Reset Interrupt flag */
    flag = 0;
    Serial.println("ping ! ");
    Serial.println(count);
  }

}


void intInt()
{
  flag = 1;
}

Let me know if it works on your side.
Basically, it is normal to have debouncing when the button is pushed and when the button is released. In order to filter these events, you need to put a delay just after the first interrupt trigger and just after the release event. In this way, obviously the ISR is called several times, but you should enter into the check block just once.
Best Regards,
Carlo

Thanks for your reply :)

Yeah it could be a solution but as I'm designing a very low power device, spend 100ms just for debounce is a pretty big waste ... And it's not the behaviour you usually get in Arduino environnement so ...

I close this one as it is superseded bu #1602